Computer networks provide transmission paths between host computers, allowing different host computers to communicate and exchange information with each other. Hosts communicate with each other using established communication protocols.
Transmission Control Protocol/Internet Protocol (TCP/IP) is a set of protocols that allows host computers to share resources across a network. The Internet computer network utilises TCP/IP to enable many computers to communicate with each other. Smaller sub-networks connected to the Internet and private networks also utilise TCP/IP to share network resources among cooperating host computers.
The Internet Protocols (IP) are responsible for routing individual datagrams from a source host computer to an intended destination host computer. Each host connected to an IP network is allocated one or more unique IP addresses. Hosts are allocated addresses either manually or through a Dynamic Host Configuration Protocol (DHCP) server. DHCP is a protocol for automating the configuration of computers that use TCP/IP. Once a host is allocated an address, the host may register its name and address(-es) with a Domain Name System (DNS) server. Registration of the address is performed manually or automatically using a dynamic DNS update protocol.
On a network layer, the IP communication protocols include Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). An IPv4 address is a 32-bit number that is typically written as four octets in a “dotted decimal number”. An example of an IPv4 address is 215.24.61.139. An IPv6 address is a 128-bit number that is typically expressed using “colon-hexadecimal” notation. Colon-hexadecimal notation divides a 128-bit number along 16-bit boundaries and delimits each 16-bit block with colons. An example of an IPv6 address is 20db:12f3:9c5a:130:fe28:2f3b:f4:1234. IPv6 addresses may also be expressed using the dotted decimal notation. The IPv6 address used as an example above, 20db:12f3:9c5a:130:fe28:2f3b:f4:1234, is written in dotted decimal notation as 8411.4851.40026.304.65064.12091.244.4660. A 16-bit block of contiguous zeros in an IPv6 address may be written in a compressed format as ::, which is known as a “double-colon”.
A host that is only capable of operating using the IPv4 protocol is unaware of any IPv6 traffic emanating from an IPv6 host. Similarly, a host only capable of operating using the IPv6 protocol is unaware of any IPv4 traffic on the network. Difficulties arise when hosts operating different protocols want to communicate with one another. A dual-stack host is capable of operating using both protocols. Consequently, a dual-stack host on the Internet computer network is able to communicate with IPv4 hosts and IPv6 hosts.
A translator typically resides at the network layer. The primary functionality of the translator is to modify packet headers, such as translating an IPv4 packet header to an IPv6 packet header and vice versa. Translators include Network Address Translator (NAT) and Stateless Internet Protocol/Internet Control Message Protocol Translator (SIIT).
A proxy is a mechanism that typically operates at the transport layer. Proxies may also operate on higher layers of the Open Systems Interconnect (OSI) Reference Model. An example is where a proxy residing at a gateway terminates a TCP connection from an internal host and initiates a subsequent TCP connection to a target external host. The first leg of the connection could be an IPv4 TCP connection and the second leg an IPv6 TCP connection. An example of a proxy is FaithD.
IPv4/IPv6 translation mechanisms rely heavily on DNS requests to trigger automatically the synthesis of appropriate DNS resource records (RRs) such that two hosts with incompatible stacks are able to communicate through a proxy or translator. Examples of translation/transition mechanisms include Network Address Translation—Protocol Translation (NAT-PT), FaithD and SIIT.
A Domain Name System Application Level Gateway (DNS-ALG) plays a significant role in the operation of translation/transition mechanisms. The DNS-ALG is responsible for intercepting DNS requests from hosts, determining the capabilities of target hosts, and synthesizing appropriate RRs that cause all packets from a requesting host to be routed through a given translation/transition mechanism. For example, a DNS query from an IPv6 host for an AAAA/A6 resource record-(RR) of an IPv4 host results in the synthesis of an AAAA/A6 RR constructed from a translator/proxy specific IPv6 prefix and the IPv4 host's address.
DNS-ALG is also responsible for creating dynamic mappings at the onset of IPv4-only to IPv6-only communications. The DNS-ALG creates a dynamic mapping containing the IPv6 address of the last queried IPv6 host whenever an IPv4 host wants to talk to an IPv6 host. The dynamic state serves to associate an incoming connection with the last DNS query so that a translator/proxy knows for which IPv6 host an incoming IPv4 connection is destined.
Networks that contain IPv4 and IPv6 hosts utilise IPv4/IPv6 translators to facilitate communication between IPv4 and IPv6 hosts. A DNS server in such a network is not usually aware of any translation capabilities. “Network Address Translation—Protocol Translation(NAT-PT)” G. Tsirtsis and P. Srisuresh (2000), IETF RFC 2766 provides an Application Level Gateway (ALG) that acts as a proxy to a DNS server. The ALG appears to be a normal DNS server to each host on the network. In such a network, all of the hosts are configured to send DNS queries to the DNS-ALG. Typically, DNS requests are intercepted by a DNS-ALG that is aware of a special prefix used by a given IPv4/IPv6 translator/proxy. The DNS-ALG determines the address types involved, IPv4 or IPv6, depending on the address type queried and the address type(s) registered in the DNS. The DNS-ALG then returns an address constructed from a special prefix to the query host, resulting in a connection being established to the translator/proxy instead of the true destination host.
FIG. 1 shows a schematic block diagram representation of a portion 100 of a Prior Art network that utilises a DNS-ALG. A host 110 sends a DNS request 115 to a DNS-ALG 120 for an address of an intended destination host. The DNS-ALG 120 receives the request 115 and forwards the request 125 to a DNS server 130 for resolution. The DNS server 130 responds to the DNS-ALG 120 with a reply 135. If the DNS-ALG 120 receives a positive reply, the DNS-ALG 120 does not perform additional processing and the DNS-ALG 120 returns a resolved address to the Host 110 in message 140.
If the DNS server 130 is unable to resolve the initial request 125, the reply 135 from the DNS 130 is negative, indicating the address of the intended destination host was not found. The DNS-ALG 120 receives the negative reply 135 and sends a second query to the DNS-server 130, the second query being different from the initial query. If the initial query was for an A RR, an IPv4 address, the second query is for an AAAA/A6 RR, an IPv6 address. In this first scenario, a positive reply from the DNS server 130 to the DNS-ALG 120 indicates that the intended destination host has an IPv6 address, rather than an IPv4 address. Conversely, if the initial query was for an AAAA/A6 RR, an IPv6 address, the second query is for an A RR, an IPv4 address. In this second scenario, a positive reply from the DNS server 130 to the DNS-ALG 120 indicates that the intended destination host has an IPv4 address, rather than an IPv6 address.
The DNS-ALG 120 establishes an appropriate mapping, if necessary, and returns an address with a special prefix in message 140 to the host 110. The special prefix causes all packets with an address bearing that prefix to be routed to an IPv4/IPv6 translator/proxy. Host 110 uses the address when sending datagrams intended for that destination host. The special prefix in the address ensures that all packets carrying the address are routed to a translator/proxy.
In a preferred embodiment, the initial request 125 from the DNS-ALG 120 to the DNS server 130 includes a query for each of the A and AAAA/A6 RRs of the intended destination host. The DNS-ALG responds to the DNS-ALG 120 with a reply 135 that indicates whether the DNS server 130 is able to resolve either an IPv4 or an IPv6 address for the intended destination host. The DNS-ALG 120 determines from the reply 135 whether the host 110 and the intended destination host are compatible and establishes an appropriate mapping, if necessary.
The use of a DNS-ALG relies on the existence in the network of a centralised name server to determine whether a translator is required to facilitate communication between hosts operating in accordance with different protocols.
Upon receipt of an incoming connection, the translator/proxy may ask the DNS-ALG for the true destination or address. Alternatively, the translator/proxy may be able to infer the address from the destination address of the incoming connection. The translator/proxy then sets up a subsequent connection or translates all packet headers appropriately. The IP address of the DNS-ALG is usually passed to end hosts through DHCP as the address of the name server. As a result, all DNS requests are intercepted by the DNS-ALG, which determines whether a translator or proxy needs to be involved to facilitate the communication.
A network using a multicast domain name system (mDNS) may include a number of hosts distributed across the network, each host maintaining its own name and other resource records. There is no central node, such as a conventional DNS server, in which DNS requests can be intercepted and processed to determine whether a translator/proxy needs to be invoked to enable subsequent connections. Accordingly, each host is responsible for performing name-to-address resolution.
Network Basic Input Output System (NetBIOS) is another example of a multicast network. In NetBIOS multicast environments, a dual-stack host comprising a multicast NetBIOS Application Level Gateway (mNetBIOS-ALG) listens to NetBIOS requests. The mNetBIOS-ALG performs in a similar manner to the DNS-ALG described above to determine the capabilities of an intended destination host. However, the mNetBIOS-ALG operates on NetBIOS packets transmitted over IPv4 and IPv6, rather than DNS requests.
A further example of a multicast network is Service Discovery Protocol (SDP). To determine the capabilities of an intended destination host, a multicast Service Discovery Protocol Application Level Gateway (mSDP-ALG) listens to service discovery requests transmitted from IPv4 and IPv6 nodes. The mSDP-ALG determines the capabilities of an intended destination host be retransmitting a received Service Location Protocol (SLP) query over IPv4 or IPv6. The intended destination host may then reply using either IPv4 or IPv6, depending on the destination host's capabilities. The reply from the destination host may also include service attributes including IPv4 or IPv6 addresses.
Once the mSDP-ALG determines the capabilities of the destination host, the mSDP-ALG synthesizes an address and rewrites all IP addresses in the SLP reply from the destination host with the synthesized address. Thus, if the destination host is IPv6 and the source host is IPv4, all IPv6 addresses in the SLP reply from the destination host are rewritten as a synthesized IPv4 address. Alternatively, if the destination host is IPv4 and the source host is IPv6, all IPv4 addresses in the SLP reply from the destination host are rewritten as a synthesized IPv6 address.
As mDNS networks do not feature a central name server, a mechanism does not exist for determining when protocol conversion is required to allow hosts using different protocols to communicate with each other. Thus, a need exists to improve communication capabilities among host computers in a multicast computer network.